Death of an Open Source Business Model
Eulogy for a simpler time
I work at Azavea, but this is my personal blog. What’s written here is my personal opinion and nothing more. Yadda, yadda, yadda.
The news yesterday that the new version of Mapbox GL JS will be proprietary shook me.¹
I am not a zealot. I do not feel entitled to others’ intellectual property, even if they’ve given away their ideas in the past. I know from experience how exhausting, thankless, and exploitative the work of creating and maintaining open source software can feel.
Until yesterday, I was still clinging to a few shreds of romantic optimism about open source software businesses. Mapbox is the protagonist of a story I’ve told myself and others countless times. It’s a seductive tale about the incredible, counterintuitive concept of the “open core” business model for software companies. In a piece I wrote last year that no one read, I defined the open core strategy thusly:²
“Open core” businesses offer a free, open source version of their software and a paid version with additional proprietary features that would be a pain to replicate […]
For the best in-depth analysis of the concept of the “open core” business model I’ve come across, I highly recommend reading Joseph Jacks’ blog post Open Core — Definition, Examples & Tradeoffs.
The whole idea is insane. No one believes it could possibly work when they first learn about it, and yet dozens of companies like Elastic, D2iQ (formerly Mesosphere), MongoDB and Cloudera have all managed to achieve valuations in the billions of dollars by pursuing this batshit-crazy, reverse-psychology, let-it-all-hang-out strategy. Or, at least, they were open core businesses at some point…maybe not so much today. More on that later.
Today, we’re gathered here on the internet to mourn the death of the open core business model. We’re here to tell stories of the before-times, to reminisce about how smart we thought we were. We went against consensus, and we were wrong. Because, open core is dead.
Cloud killed open core.
Back to Mapbox
In the case of Mapbox GL JS, Mapbox had previously decided to openly license the first two versions of the their browser-based map renderer (the same one that powers Snap Maps, the New York Times, and CNN among myriad others). Ever since the initial release in 2014, it’s been incredibly popular among web developers. Once you know what you’re looking for, you start to see it…everywhere.
I personally experienced the power of Mapbox GL JS when my team at Azavea started building GroundWork, a tool for labeling satellite imagery. Using functionality from that library, GroundWork supports freeform drawings of complex geometries. The resulting shapes are cartographic — they’re projected onto a real location on earth, not just suspended in imaginary 2D space. It’s the type of feature that feels obvious and straightforward but is in fact extraordinarily difficult to engineer from scratch.
Even simple-looking shapes drawn with a freehand technique can contain thousands of individual vertices. Pretty quickly, you fill up your screen with hundreds of thousands of vertices worth of shapes and…oh, poop-and-a-half.³ Your browser crashes.
Mapbox GL JS helps to circumvent that problem by summoning help from the graphics card on your machine. There’s no way we could have built that feature within our budget and time constraints without piggybacking on Mapbox’s tens of thousands of hours of hard, low-level engineering work.